home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 6343 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.2 KB
  1. Path: dlmlap.supra.com!dan
  2. From: dan@supra.com (Dan Moore)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: Supra will offer upgrade to 33.6!
  5. Date: Tue, 27 Feb 1996 15:27:08 GMT
  6. Organization: Supra Corporation
  7. Message-ID: <dan.894.313322CC@supra.com>
  8. References: <312172b0.302209@uchinews.uchicago.edu> <4ftaot$rpc@shellx.best.com> <31226a7d.63749347@uchinews.uchicago.edu> <4g182k$1mu2@navajo.gate.net> <31243778.561299@uchinews.uchicago.edu> <4g3t66$26um@hopi.gate.net> <dan.878.312C8AD9@supra.com> <dan.
  9. NNTP-Posting-Host: dlmlap.supra.com
  10. X-Newsreader: Trumpet for Windows [Version 1.0 Rev B.7]
  11.  
  12. In article <4gt5jg$tte@hopi.gate.net> dhaire@gate.net (doug haire) writes:
  13. >Dan Moore (dan@supra.com) wrote:
  14. >:         In V.34 a rate renegotiation is simply a change in the bits per
  15. >:symbol without changing the symbol rate.   This is a very quick change
  16. >:since no probing, etc. is done.   When a modem initiates a rate
  17. >:renegotiation there is no requirement that the remote modem accept the
  18. >:rate change, during the parameter exchange it can refuse to change the
  19. >:rate.   Typically modems always accept rate renegotiations downward and
  20. >:may refuse rate renegotiations upwards if the current EQM is too high.  If
  21. >:a rate renegotiation fails (ie. the remote modem doesn't respond at all) a
  22. >:retrain will occur instead.
  23. >Not if both modems are defaulted to *not* initiating a retrain.
  24.  
  25.          Why do you say that?   I'm describing the behaviour that is required 
  26. by the ITU-T recommendation V.34 in sections 11.5 (Retrains), 11.6 (Rate 
  27. Renegotiation) and 11.6.2 (Recovery Mechanism).  This is the behaviour 
  28. implemented by the firmware in Supra's V.34 products.   All of the V.34 
  29. products I have examined implement this exact same behaviour.
  30.  
  31. >:         The protocols that support rate renegotiation (V.32bis, VFC and
  32. >:V.34) all require a modem to follow a remote rate renegotiation request.
  33. >:So no matter how the local modem is configured to do rate changes if the
  34. >:remote modem initiates a rate renegotiation the local modem must respond
  35. >:to it.  If the remote modem uses a retrain to change data rates the local
  36. >:modem must respond to that also. 
  37. >Yes, but if *both* modems are Supras, no retrain will be initiated so 
  38. >neither one will have to respond since the request will never be given. 
  39. >Instead, a few rate changes will be tried (allegedly) and carrier will be 
  40. >lost.
  41.  
  42.         This is *NOT* true.  If a rate renegotiation fails (ie. the remote 
  43. modem does not respond with signal E within the timeout period) a retrain will 
  44. be initiated.  This is documented in section 11.6.2 (Recovery Mechanism).   
  45. The timeout period depends on the setting of bit 24 of the INFO0 sequence 
  46. received from the remote modem, if it is a 1 the timeout is 30 seconds, if it 
  47. is a 0 the timeout is 2500ms plus 2 times the round trip delay.
  48.  
  49.         The behaviour of the modem when a failed rate renegotiation occurs 
  50. is not controlled by any S register or command.  It is specified in 
  51. recommendation V.34 and is not subject to user control.
  52.  
  53. >While I agree that many programs have really old init strings, that is an 
  54. >incredibly stupid reason to leave otions in. In addition, there is 
  55. >nothing consistent about extended commands for high speed modems. Even 
  56. >the Rockwell chipset based modems have some differences in these. I 
  57. >really don't believe that Supra used this rational or that even Rockwell 
  58. >(who really is the owner of the command set) used that rationale when 
  59. >designing the command set to be used.
  60.  
  61.         I agree that the AT command set is not very standard.  This is why the 
  62. ITU-T has written recommendation V.25ter and is working on recommendation V.ib 
  63. (and several others).
  64.  
  65.         A lot of the things done by Rockwell and by us are done for backward 
  66. compatibility.   If leaving in an old option prevents one tech support call a 
  67. week then it is worth the effort.   There are hundreds of old data and fax 
  68. programs that issue commands that make little sense on current modems.  There 
  69. are also many old programs with built in init strings that can not be 
  70. changed.  We (and many other companies) still implement these commands because 
  71. we can't force our customers to use new software.  This is the same reason 
  72. Microsoft still carries around a lot of obsolete DOS calls in Windows 95 (and 
  73. Windows NT).   Backward compatiblity is a pain, but it is something consumers 
  74. expect.
  75.  
  76. >I appreciate your attempt to explain but I think you have consistently 
  77. >missed the point.
  78.  
  79.         Actually I think you, like many other people, don't really understand 
  80. the difference between a rate renegotiation and a retrain.  Rate 
  81. renegotiations have been the recommended method of changing data rates since 
  82. the CCITT released recommendation V.32bis.   Rate renegotiations are a much 
  83. quicker way of changing data rates when the line conditions (as measured by 
  84. the EQM) change.  Retrains are much slower, but they do allow the complete 
  85. reprobing of the line conditions.   Modems (including Supra products) still 
  86. implement retrains and will use them when there is a large enough change in 
  87. line conditions.   (As my previous message stated, if the EQM is high enough 
  88. the modem will initiate a retrain no matter how %E and %G are set.)
  89.  
  90. --
  91. Dan Moore
  92. Supra
  93.  
  94.  
  95.  
  96.  
  97.  
  98.